The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Some users are reporting that they don't see Live Activities, but our logs show that the trigger was sent successfully. Is there a way to investigate on the client side why the Live Activity didn't appear? Logs on client side? anything?

I'm working on adding Live Activities to my app but I'm running into a problem, and I'm wondering if anyone knows what's going on. The live activities are started and updated entirely via push notifications (sent through FCM). On the lock screen, updates come through fine for a while, but then the activity gets stuck while the phone is locked. The moment I unlock the device, it immediately jumps to the latest state. I've tried different update frequencies and sending with both priority 5 and priority 10, but no luck. I've also looked through the liveactivitiesd logs, but I'm not really sure what I should be looking for. And yes, NSSupportsLiveActivitiesFrequentUpdates is enabled.

Hi everyone, We have an iOS app that is currently live on the App Store under Company 1's Apple Developer account, and we are planning to transfer it to Company 2's Apple Developer account using Apple's App Transfer process. Our current push notification setup is as follows: Push notifications are sent using Firebase Cloud Messaging (FCM). Firebase is configured with an APNs Authentication Key (.p8) generated from Company 1's Apple Developer account. The app uses the same Bundle ID before and after the transfer. We would like to understand the expected behavior after the app transfer. Our questions are: Will users who already have the app installed continue to receive push notifications after the app has been transferred? Once the app is owned by Company 2, will the APNs Authentication Key from Company 1 continue to work, or must it be replaced immediately with a new key generated from Company 2's Apple Developer account? Is there any supported way to configure APNs so that both the old and new APNs Authentication Keys can be used during the migration period, allowing push notifications to be delivered seamlessly to all users? 3)If simultaneous APNs keys are not supported, what is the recommended migration strategy to avoid any interruption in push notification delivery during the transfer? Our goal is to ensure that existing users continue receiving push notifications without disruption while we complete the App Store transfer. Any guidance or best practices from Apple or developers who have gone through a similar migration would be greatly appreciated. Thank you!

Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

I create a Live Activity remotely via push-to-start, then use its per-activity token (Activity.pushTokenUpdates) so my server can send update/end pushes. To make sure I'm not missing tokens, I observe Activity.activityUpdates and prime from the Activity.activities snapshot at launch and on sceneWillEnterForeground, then subscribe each activity's pushTokenUpdates and POST the token to my server. This works reliably while the app is running or backgrounded/suspended — the system wakes it and I capture the token. The problem is the user force-quit case (swiped from the App Switcher, never reopened): Push-to-start still creates the Live Activity and it renders correctly on the Lock Screen. But pushTokenUpdates never fires, so my server never receives the per-activity token and can't update or end that activity. A backgrounded (not force-quit) app, as a control, captures the token every time. So it seems specific to user-termination rather than all "not running" states. I understand force-quit apps generally aren't granted background runtime — I'm trying to confirm whether that applies here and what the right pattern is. What's the recommended approach? Specifically: Is there any supported way to get the per-activity token to my server while the app stays force-quit — e.g. from the widget extension (does it have any access to Activity.pushToken, or only ActivityViewContext?) or a Notification Service Extension? 2. If not, is setting stale-date on the start push the intended way to let the card expire gracefully when it can never be ended via push? 3. Is there a better pattern for keeping a push-started Live Activity correct when the app is never relaunched?

Hello, I am implementing background processing using Silent Push Notifications in an iOS application. The app needs to receive requests from a server and execute processing in the background. For this purpose, I am using Silent Push Notifications to wake up the application. However, the application is not being launched as expected when running the TestFlight version. I would appreciate any guidance regarding this behavior. Environment Xcode 26.3 iOS 18.6 TestFlight distribution Push Notifications capability enabled Background Modes enabled Remote notifications enabled APNs Authentication Key (.p8) APNs Production environment Background Previously, the application periodically connected to a server in the background and sent location information when requested by the server. Since that background processing no longer behaves as expected, I started implementing an alternative approach using Silent Push Notifications. When running the application directly from Xcode in Debug mode, Silent Push works correctly and the app is launched in the background. However, when using the TestFlight build on the same device, the behavior differs and the app is not launched in the background. Observed Behavior The APNs request appears to be successful: APNs response status is HTTP 200 Using the device token obtained from the TestFlight build Alert Push notifications are received successfully application:didReceiveRemoteNotification:fetchCompletionHandler: is called when the app is in the foreground The same method is not called when the app is in the background Silent Push payload: { "aps": { "content-available": 1 } } HTTP/2 headers: apns-push-type: background apns-priority: 5 Verified Items Production device token is being used APNs topic matches the application's bundle identifier Alert Push notifications work correctly Background App Refresh is enabled on the device The application has not been force-quit completionHandler is always called after processing completes Console Logs The following logs appear when the push is sent: Submitted: com.apple.pushLaunch.jp.co.comp.MyApp.ext.mdm Application Policy response: {100, 0.00, [{[pushDisallowed]: Required:0.00, Observed:1.00},]} Decision: AMNP I also see: Insufficient history window for deviceActivityLikelihood stream deviceActivityLikelihood returned a nil timeline Questions Under what conditions are pushDisallowed and Decision: AMNP generated? What factors can cause iOS to reject a background launch triggered by a Silent Push Notification? Since Alert Push notifications are received successfully, is it reasonable to conclude that APNs configuration, topic configuration, and device token usage are correct? Are there any specific settings, entitlements, or implementation details that should be reviewed to resolve the pushDisallowed condition? The behavior differs between the Debug build launched from Xcode and the TestFlight build running on the same device. Are there any restrictions, policies, or differences applied to TestFlight builds that could explain this behavior? If the observed behavior is expected by design, what would Apple recommend as the appropriate architecture or API for server-triggered background processing in this scenario? Thank you for your time and assistance.

Good morning, We are implementing Live Activities in a push-to-start flow. We wrap the listener for push to start tokens in a high priority task: if ptsListenerTask == nil || ptsListenerTask?.isCancelled == true { ptsListenerTask = Task(priority: .high) { [weak self] in for await pushToken in Activity<LiveAuctionAttributes>.pushToStartTokenUpdates { //Send token to back-end } } I've tried a few variations of this and they work well on most devices. I have seen a couple of devices that refuse to issue a push to start token. The user will have logging for the init flow and starting the PTS listener then the logs just go silent, nothing happens. One thing that seemed to work was getting the user to start a Live Activity manually (from our debugging tool) then the PTS token gets issued. This is not very reliable and working a mock live activity into the flow for obtaining a PTS token is a poor solution. Is anyone else seeing this and is there a known issue with obtaining PTS tokens? Thanks! Brad

We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation. We have captured full system logs across three separate incidents. Below are the exact log sequences. Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams) Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA) The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app. 17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0 ↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min). 17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome ↑ LTE cell handover triggers RRC reconnect. 17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)] event: path:satisfied_change @594.391s ↑ APNs path re-satisfied. Reconnection begins. channel-flow viable NOT yet reached — TLS handshake still in progress. 17:48:08.057 apsd Powerd has requested assertion activity update ↑ Warning: powerd about to change policy. ── 2 minutes 40 seconds after APNs reconnect started ── 17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3 17:48:41.250 apsd Update assertion policy 3 17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0 17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0 ↑ Screen off, device locked. OS enters restricted idle. apsd restricted. APNs reconnection abandoned. 17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort nexus error (2) for pid 1518 Comera ↑ Kernel terminates Comera's network stack via NECP. No API available to prevent this. WhatsApp and Teams remain suspended — no DEFUNCT, but apsd in policy 3 means no push delivery for them either. ── Dead zone: VoIP pushes for all 3 apps undeliverable ── 17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive "com.apple.ipTelephony.sipIncoming.cell" ↑ Incoming cellular PSTN call forces system wake. 17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0 17:50:04.598 apsd Update assertion policy 0 ↑ Full wake. Queued VoIP pushes from Comera, WhatsApp, and Teams are delivered simultaneously. Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action. Working case (same test, different conditions) Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot 19:2x:xx apsd policy state {downgradeWhenLocked: NO, isSystemLocked: NO, isConnectedOnUltraConstrainedInterface: NO} ↑ Device unlocked. No policy 3. Comera NOT defuncted. Push delivered. Call rings normally. Our implementation PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement Questions Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario. Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd? Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window? What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period? Full log stream captures available for all incidents.

I'm trying to nail down the correct mental model for keeping a push-to-start Live Activity updatable, and want to confirm my understanding rather than design around an assumption. Flow: my server creates the activity via push-to-start, then I capture its per-activity token (Activity.pushTokenUpdates) and send it to the server for update/end pushes. I observe Activity.activityUpdates and also prime from the Activity.activities snapshot at launch and on foreground. What I'd like to understand for each app state: Foreground / backgrounded (in memory): I capture the token reliably — is that the intended guarantee? System-terminated (jettisoned for resources): does the system relaunch the app in the background to deliver the per-activity token, and is that something I can rely on? User force-quit (swiped from the App Switcher, not reopened): what should I expect here for per-activity token delivery, and what's the recommended strategy if the app stays force-quit — e.g. stale-date on the start push for graceful expiry, or any extension-based path? Essentially: across these states, what's the supported strategy to keep a push-started Live Activity correct? Tested on iOS 18 and 26. Related question from the implementation side: https://developer.apple.com/forums/thread/834934

Hi Team We are building a live activity feature for our app. While using the APNS broadcast API (https://api.push.apple.com:443/4/broadcasts/apps/), we are getting throttled. The updates are infrequent (sport games) and yet we are facing this issue. Our understanding was that the throughput is quite high but there is no documentation on the actual limitations. Furthermore, all of our updates are using a priority of 5. We have currently configured retry with exponential backoff and jitter but we would like to understand the APNS throttle limit for live activity broadcast. Is the limit per channel id or at API level? What is the hard limit for the API request per seconds? Can we request increase to the API rate limit?

Problem Description We are encountering a pushToken retrieval failure when creating Live Activities using the ActivityKit framework in our iOS application. Problem Symptoms Failure Rate: Approximately 40% of Live Activities created in production fail to obtain a pushToken Behavior: The Activity is created successfully, but activity.pushToken and the activity.pushTokenUpdates stream remain empty / return nothing Impact: Unable to update Live Activities via APNS Offline Issue Environment iOS Version: iOS 26.5 Device: Physical iPhone device Deployment Environment: Production environment, release build Code Sample Task { // Executed after Live Activity creation for await activity in Activity<T>.activityUpdates { ... if let activityTokenData = activity.pushToken { // Report token to APNS service reportTokenToAPNS(tokenString) } // Start async monitoring self.registerPushTokenUpdates(...) Log("actObserver: Live Activity registered successfully") } } // Async monitoring private func registerPushTokenUpdates<T: SAKActivityAttributes>(...) { Task { self.pushTokenObserveRecords.safe{ $0.append(activity.id) } Log("Monitoring pushToken updates for Live Activity <\(activity.id)>") for await data in activity.pushTokenUpdates { let pushToken = pushTokenString(with: data) // Report token to APNS service reportTokenToAPNS(pushToken) } } } System Log Evidence System logs, log and log

We are observing multiple different deviceId values linked to the same user within short timeframes. In some instances, a new deviceId appears every few minutes or hours. We utilize this identifier for managing Apple Wallet pass updates. We would appreciate understanding which scenarios might cause the deviceId to change. Could it be influenced by: Device restoration or factory reset procedures App reinstallation or data clearing iOS version updates iCloud account changes or Apple ID authentication status changes Privacy feature activation (such as App Tracking Transparency or Private Relay) Testing environment usage (simulators or automated testing frameworks) We aim to determine whether this behavior is expected or if it suggests atypical usage patterns. Thank you for your assistance!

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer

so the app is free to download . the first use is free for two days . We want to send a reminder to them via email. some are installing (67%) but not returning to use the free credit. what is the policy on getting the apple id from apple. do we have to ask the user for the id at install and then disclose that its for tracking purposes and to inform about future promo's . the id will not be shared with third parties

Hi everyone, I'm working on a Live Activity implementation for a ticketing app (written in Swift/SwiftUI with ActivityKit), and I've encountered an unexpected behavior on iOS 26.2.1 that contradicts my understanding of the documentation. What the docs say: The official ActivityKit documentation states: "The system uses the minimal presentation when more than one app has an active Live Activity." This implies the two minimal slots are intended for two different apps. There is no documented scenario where a single app occupies both minimal positions simultaneously. What I observed: On a device running iOS 26.2.1, with two active Live Activities from the same app running at the same time, both minimal views appeared on the Dynamic Island simultaneously — one attached to the island, one as a detached floating pill. Questions: Is this behavior intentional in iOS 26, or is it a regression / unintended side effect? Has the system policy changed in iOS 26 to allow a single app to occupy both minimal slots? If this is expected, is there any updated documentation or release notes that cover this change? Environment: Device: iPhone 14pro iOS: 26.2.1 Xcode: xcode26 Any insights from Apple engineers or developers who've seen this would be greatly appreciated. Thanks!

Populating widgets with silent push notifications would be great for us if they were more predictable. Can you share tips for debugging / testing in Test Flight beyond the usual recommendations available online? When messages are not processed it is a major challenge to distinguish between code problems and device throttling.

In an MSP environment, we manage hundreds of Mac based client organizations. It would be really helpful to have support in the Apple Business API for automating APNS certificate and ADE / Apps & Books token renewal. Thanks!